Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8343840: Rewrite the ObjectMonitor lists #23421

Closed

Conversation

fbredber
Copy link
Contributor

@fbredber fbredber commented Feb 3, 2025

I've combined two ObjectMonitor's lists, EntryList and cxq, into one list. The entry_list.

This way c2 no longer has to check both EntryList and cxq in order to opt out if the "conceptual entry list" is empty, which also means that the constant question about if it's safe to first check the EntryList and then cxq will be a thing of the past.

In the current multi-queue design new threads where always added to the cxq, then ObjectMonitor::exit would choose a successor from the head of EntryList. When the EntryList was empty and cxq was not, ObjectMonitor::exit whould detached the singly linked cxq list, and add the elements to the doubly linked EntryList. The element that was first added to cxq whould be at the tail of the EntryList. This way you ended up working through the contending threads in LIFO-chunks.

The new list-design is as much a multi-queue as the current. Conceptually it can be looked upon as if the old singly linked cxq list doesn't end with a null pointer, but instead has a link that points to the head of the doubly linked entry_list.

You always add to the entry_list by Compare And Exchange to the head. The most common case is that you remove from the tail (the successor is chosen in strict FIFO order). The head is volatile, but the interior is stable.

The first contending thread that "pushes" itself onto entry_list, will be the last thread in the list. Each newly pushed thread in entry_list will be linked trough its next pointer, and have its prev pointer set to null, thus pushing new threads onto entry_list will form a singly linked list. The list is always in the right order (via the next-pointers) and is never moved to another list.

Since we choose the successor in FIFO order, the exiting thread needs to find the tail of the entry_list. This is done by walking from the entry_list head. While walking the list we assign the prev pointers of each thread, essentially forming a doubly linked list. The tail pointer is cached in entry_list_tail so that we don't need to walk from the entry_list head each time we need to find the tail (successor).

Performance wise the new design seems to be equal to the old design, even though c2 generates two less instructions per monitor unlock operation.

However the complexity of the source has been reduced by removing the TS_CXQ state and adding functions instead of inlining cmpxchg here and there, and the fact that c2 no longer has to check both EntryList and cxq makes this PR worthwhile, I think.

Tests tier1-7 passes okay as well as micro-benchmarks like vm.lang.LockUnlock.
Unsupported platforms { ppc, riscv, s390 } has been tested with QEmu.


Progress

  • Change must be properly reviewed (1 review required, with at least 1 Reviewer)
  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue

Issue

  • JDK-8343840: Rewrite the ObjectMonitor lists (Enhancement - P4)

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/23421/head:pull/23421
$ git checkout pull/23421

Update a local copy of the PR:
$ git checkout pull/23421
$ git pull https://git.openjdk.org/jdk.git pull/23421/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 23421

View PR using the GUI difftool:
$ git pr show -t 23421

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/23421.diff

Using Webrev

Link to Webrev Comment

@bridgekeeper
Copy link

bridgekeeper bot commented Feb 3, 2025

👋 Welcome back fbredberg! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk
Copy link

openjdk bot commented Feb 3, 2025

@fbredber This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8343840: Rewrite the ObjectMonitor lists

Reviewed-by: dholmes, coleenp, pchilanomate, yzheng

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 169 new commits pushed to the master branch:

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

@openjdk
Copy link

openjdk bot commented Feb 3, 2025

@fbredber The following labels will be automatically applied to this pull request:

  • graal
  • hotspot

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

@fbredber fbredber marked this pull request as ready for review February 25, 2025 13:14
@openjdk openjdk bot added the rfr Pull request is ready for review label Feb 25, 2025
@mlbridge
Copy link

mlbridge bot commented Feb 25, 2025

Webrevs

Copy link
Member

@dholmes-ora dholmes-ora left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Disclaimer for other reviewers, I have been looking at this code for some time now.

Overall code looks good. I have quite a few comments/suggestions about comments.

I suggest renaming _vthread_cxq_head to just _vthread_head as the cxq part is no longer meaningful.

I agree that even though this seems performance neutral, the code simplification (for people reading it for the first time) will be worth it.

Thanks.

Copy link
Contributor

@coleenp coleenp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks really good - I have some small change and improvement requests.

Copy link
Contributor

@coleenp coleenp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change looks great. Thank you!

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Feb 27, 2025
@fbredber
Copy link
Contributor Author

I've used QEMU to smoke test this PR on ppc64le, riscv64 and s390x, But it would be nice if @TheRealMDoerr, @RealFYang and @offamitkumar could check if it runs okay on real hardware as well.

@fbredber
Copy link
Contributor Author

@pchilano
Since I have removed the cxq list @dholmes-ora suggested that I should also rename _vthread_cxq_head. Thereby removing the term "cxq" altogether. I chose to rename _vthread_cxq_head with _vthread_list_head. Hope that is okay.

@RealFYang
Copy link
Member

I've used QEMU to smoke test this PR on ppc64le, riscv64 and s390x, But it would be nice if @TheRealMDoerr, @RealFYang and @offamitkumar could check if it runs okay on real hardware as well.

FYI: hs:tier1 - hs:tier3 test good on linux-riscv64 platform.

Copy link
Member

@dholmes-ora dholmes-ora left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay that's good enough for me. :)

Thanks

@offamitkumar
Copy link
Member

I've used QEMU to smoke test this PR on ppc64le, riscv64 and s390x, But it would be nice if @TheRealMDoerr, @RealFYang and @offamitkumar could check if it runs okay on real hardware as well.

Tier1 test passed on s390x.

@TheRealMDoerr
Copy link
Contributor

I've used QEMU to smoke test this PR on ppc64le, riscv64 and s390x, But it would be nice if @TheRealMDoerr, @RealFYang and @offamitkumar could check if it runs okay on real hardware as well.

The PPC64 code looks correct and some quick tests have passed. I'll run larger test suites over the weekend.

@TheRealMDoerr
Copy link
Contributor

I've used QEMU to smoke test this PR on ppc64le, riscv64 and s390x, But it would be nice if @TheRealMDoerr, @RealFYang and @offamitkumar could check if it runs okay on real hardware as well.

The PPC64 code looks correct and some quick tests have passed. I'll run larger test suites over the weekend.

Test results look good (including tier 1-4 on many platforms). I didn't see any new issue related to this.

Copy link
Contributor

@pchilano pchilano left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes look good to me. Just a few comments.

Thanks,
Patricio

@openjdk openjdk bot removed the ready Pull request is ready to be integrated label Mar 5, 2025
@fbredber
Copy link
Contributor Author

fbredber commented Mar 5, 2025

@mur47x111
I'm getting ready to integrate. I've seen that you have created [JDK-8349711] Adapt JDK-8343840: Rewrite the ObjectMonitor lists to handle the change on your side. Do you see any reason why I shouldn't integrate, or are you fine with me integrating this PR now?

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Mar 5, 2025
Copy link
Contributor

@mur47x111 mur47x111 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

JVMCI changes look go to me! We are good to go!

Copy link
Contributor

@pchilano pchilano left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, looks good.

Copy link
Member

@dholmes-ora dholmes-ora left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

Thanks

@fbredber
Copy link
Contributor Author

fbredber commented Mar 6, 2025

Thanks everyone for the reviews, testing and Graal adaptation.

/integrate

@openjdk
Copy link

openjdk bot commented Mar 6, 2025

Going to push as commit 7a5acb9.
Since your change was applied there have been 174 commits pushed to the master branch:

  • 40f150d: 8330936: [ubsan] exclude function BilinearInterp and ShapeSINextSpan in libawt java2d from ubsan checks
  • 649ef77: 8323158: HotSpot Style Guide should specify more include ordering
  • 5c552a9: 8349358: [JMH] Cannot access class jdk.internal.vm.ContinuationScope
  • e82031e: 8350756: C2 SuperWord Multiversioning: remove useless slow loop when the fast loop disappears
  • 3626ac3: 8204868: java/util/zip/ZipFile/TestCleaner.java still fails with "cleaner failed to clean zipfile."
  • 4bb3d81: 8351138: Running subset of gtests gets error printing result information
  • 107ee87: 8346954: [JMH] jdk.incubator.vector.MaskedLogicOpts fails due to IndexOutOfBoundsException
  • 11a37c8: 8351165: Remove unused includes from vmStructs
  • c3b4819: 8351074: Disallow null prefix and suffix in DecimalFormat
  • 6012e8d: 8350808: Small typos in JShell method SnippetEvent.toString()
  • ... and 164 more: https://git.openjdk.org/jdk/compare/1e87ff01994df16df7de331040fc5d7a4a85f630...master

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Mar 6, 2025
@openjdk openjdk bot closed this Mar 6, 2025
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Mar 6, 2025
@openjdk
Copy link

openjdk bot commented Mar 6, 2025

@fbredber Pushed as commit 7a5acb9.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

8 participants